home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / ODF Container < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  2.3 KB  |  [TEXT/ttxt]
  1. Subject:     ODF Container
  2. Sent:        5/28/96 4:11 PM
  3. Received:    5/28/96 1:41 PM
  4. From:        Doyle Rhynard, doyle.w.rhynard@cpmx.saic.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8.     I was very happy to discover that ODF R1 has a container part editor. I
  9. was about to try to create something with its basic functionality, but you
  10. have saved me, and many others, the trouble.
  11.  
  12.    There is one aspect of ODFContainer, however, that bothers me. I am
  13. attempting to convert a simulation into OpenDoc parts. The initial version
  14. should have about a dozen parts that function quite closely to what is
  15. already in ODFContainer. The problem is that each one of these parts will
  16. end have a lot of code that is almost identical. As far as I can determine,
  17. most of what is being done in the container framework classes is generic
  18. and could be put into base classes. In fact, only the Part, Frame, and View
  19. classes seem to contain features that require parts of them to be varied
  20. from part to part.
  21.  
  22.     What I would like to have is a basic container framework that has most
  23. of its functionality in a shareable library, such as ODFLibrary. As in all
  24. good object oriented code designs, only the minimum amount of nonredunant
  25. code would have to be incorporated into each individual part. Since most of
  26. the new parts that will be produced in the future as likely to be based on
  27. ODFContainer, I would like to think that there is some way of reducing the
  28. their size by putting the redundant code in a common library. This approach
  29. would have the added bonus that most new users wil have a much easier time
  30. trying to understand ODF if most of the remaining complexity can be hidden.
  31. I would anticipate that new users will be able to create new parts in a
  32. fraction of the time that it is now requires since they need only
  33. concentrate on the portions that absolutely have to be modified. What would
  34. also be nice, is a set of tutorials derived from this simple container
  35. model.
  36.  
  37.     I have made two different attempts to create such a container
  38. framework, but both ended up crashing when I tried to use them. My question
  39. is, then, whether this approach is viable at all. If someone with more ODF
  40. experience can help me, please let me know.
  41.  
  42. Doyle Rhynard
  43.  
  44.